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(54) An application dispatcher for server application 



(57) A plurality of clients are connected to one or 
more servers. When a client initiates a connection with 
a server, the server responds to the request for connec- 
tion by transmitting a message back to the client to 
determine whether the client is a network terminal or 
not. The client responds with a message that is received 
by an application dispatcher at the server which takes 
one of a pair of actions based on whether the client is a 
network terminal. If the client terminal is a network ter- 
minal, then the application dispatcher starts a server 
application in the server which responds to the client 
application In the client. Going fonward. the server appli- 
cation responds to all future requests from the client 
application. If the client is not a network terminal, then 
the application dispatcher initiates a client application in 
the server to service the client terminal application 
requirements. Requests from the client application on 
behalf of the client terminal are subsequently serviced 
by a server application at the server which communi- 
cates to the client terminal via the client application at 
the server. In one embodiment, the application dis- 
patcher includes a listener. The listener is assigned to a 
particular port number of the server. The listener is 
responsible for waiting for new incoming connections 
from a client terminal (e.g., a network terminal or a non- 
network terminal). When a new incoming connection is 
detected, the listener dynamically instantiates a 
resolver and passes the connection to the resotver. The 
behavior of the resolver can vary depending n the port 
number and requirements of the client terminal. For 
example, for a network terminal, such as a commercially 



available VeriFone Personal ATM™ (PATM™) appliance 
or a Personal Computer (PC), the resolver is responsi- 
ble for executing "who are you" negotiation and for gen- 
erating a session key 
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Description 

[0001 1 The present invention generally relates to improvement in computer systems, and more particularly, to system 
software for managing a network of heterogeneous client terminals communicating with a server consistent manner. 
5 [0002] Reference is made to co-pending United States application no. 08/692.489 entitled "System Method and Arti- 
cle of Manufacture for Seamless, Server Application Support of Network and Non-Network Client Terminals", and filed 
on Augusts, 1996. 

[0003] Recently it has become increasingly fashionable to speak of "intelligent. " "smart," or "programmable" terminals 
and systems. Very few mainframe or peripheral manufacturers omit such a device from their standard product line. 

10 Although Intelligence." like beauty or art. Is in the eye of the beholder, the adjective generally connotes that the drive 
has a degree of autonomy or processing ability which allows it to perform certain tasks without assistance from the 
mainframe to which it is connected. Many such devices are programmable by virtue of including a miaoprocessor. 
[0004] While operational devices are somewhat hazy and non-standard, a device is refen-ed to as a terminal if a user 
interacts with the device to communicate to a host processor, refenred to as a server in a network computing environ- 

15 ment. Examples of terminals include keyboard/printer terminals, cathode-ray tube (CRT) terminals, remote-batch ter- 
minals, real-time data-acquisition and corrtrol t^minats, transaction and point-of sate terminals, artd smart terminals. 
[0005] A terminal is considered to be intelligent if it contains, hard-, firm-, and or software which allows it to perform 
alphanumeric or graphic message entry, display buffering, verifying, editing and block transmissions, either on host or 
human command. If the terminal contains a microprocessor which runs a standard program to service the terminal, and 

20 not arbitrary, user-loaded programs, the terminal has a fixed function, and is still just an intelligent terminal. Only when 
the device contains a general purpose computer which is easily accessible to the ordinary user for offering a wide range 
of programs selectable by a user or by devices attached to the device does tiie terminal become a network terminal in 
accordance with a preferred embodiment. 

[0006] Sun has recently introduced a new language that is designed to provide consistency for network applications. 
25 named Java. Java is a general-purpose, concunrent, class-based, object-oriented programming language and support 
structijre, specifically designed to have as few implementation dependendes as possible. Java allows application devel- 
opers to write a program once and tiien be able to run it everywhere on a computer network. 
[0007] The Java™ language solves many of tiie client-side problems by: 

30 • enabling dynamic class bindings; 

• providing enhanced portability of applications; and 

providing a secure environment in which applications execute. 

[0008] Java is compiled into bytecodes in an intermediate form instead of machine code (like C, C-f4-, Fortran, etc.). 
35 The bytecodes execute on any machine with a Java bytecode interpreter. Thus, Java applications can run on a variety 
of client machines, and the bytecodes are compact and designed to transmit efficiently over a network which enhances 
a preferred embodiment with universal clients and server-centric policies. 

[0009] With Java, developers can create robust User Interface (Ul) components. Custom "widgets" (e.g., real-time 
stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML. Java sup- 
40 ports tiie notion of client-side validation, offloading appropriate processing onto ttie client for improved performance. 
Dynamic, real-time applications can be created using the above-mentioned components. 

[0010] Sun's Java™ language has emerged as an industry-recognized language for "programming the Internet." Sun 
defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high- 
performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports 

45 programming for the Internet in tiie form of platform-independent Java applets." Java applets are small, specialized 
applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interac- 
tive content" to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within 
a Java-compatible browser (e.g., Netscape Navigator™ browser) by copying code from the server to client. From a lan- 
guage standpoint, Java's core feature set is based on C+-I-. Sun's Java™ language literature states that Java is basically 

50 "C-H-, with extensions from Objective C for more dynamic method resolution". 

[001 1 J The term "disfributed computing" refers both to the devices at remote locations and to the logic which has been 
used to enhance tiie intelligence of the devices. Such distibuted ordecenti^alized computing with remote intelligent ter- 
minals and network terminals" is a fact of life in today's computer literate society. 

[0O12] There are a number of drawbacks to distributed computing environments which are not found in a centralized 
55 conputing environment. First, hardware problems: when a user locates a software solution that is optimal for the user's 
terminal environment, the software often will not execute on the host processor tfiat is universally accessible by other's 
in a conpany. Moreover, the software will often be incompatible with other user's terminals. 

[0013] Second, interfacing problems: a nonstandard terminal might require a special-purpose interface and might not 
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be recognized by the host. Even standard interfaces are notorious for crashing the operating system. In any case, 
"mixed systems" containing multiple vendor hardware are becoming the norm, but lead to the blame for system prob- 
lems being placed oh the other system, and result in difficult debugging and resolving of system problems. 
[0014] Third, host operating system support for a heterogeneous terminal environment can be a nightmare. To pro- 
5 vide support for all of the various protocols, connmunicallon rates and processing demands with the peculiarities intrin- 
sic to a nfKJtley crew of downstream terminals is a system administration headache. 

[001 5] Fourth, local software support: this type of support ranges from minimal (e.g., a conrpiler for the particular ter- 
minal) to a mail program that is connpatible with every different terminal attached to the host server. Some applications 
can be rebuilt for a particular terminal by simply recompiling the application, but many are only distributed as runtime 
10 modules with no support provided for some terminals. 

[001 6] The present invention seeks to provide an inproved application dispatcher. 

[0017] According to an aspect of the present invention there is provided a method for an application dispatcher as 
specified in claim 1. 

[0018] The invention is also directed to a computer program embodied on a connputer-readable medium for an appli- 
15 cation dispatcher for server application support for a plurality of client terminals, the client terminals in communication 
witii a server via a network, the computer program embodied on a computer-readable medium comprising: 

a client code segment for initiating a connection to the server utilizing the network; 

a server code segment for listening for the connection utilizing the application dispatcher, the application dispatcher 
20 Starting a listener, the listener detecting the connection, the application dispatcher starting a resolver for the client 
terminal in response to the detecting of the connection, and the resolver handling the connection, and the server 
code segment further comprising logic for determining if tfie client terminal is a network terminal or a non-network 
terminal. 

25 [001 9] In an illustrative emt>odiment of the invention in a network computing environment, a plurality of clients are con- 
nected to one or more servers. When a client initiates a connection with a server, the server responds to the request for 
connection by transmitting a message back to the client to determine whether the client is a network terminal or not The 
client responds with a message tiiat is received by an application dispatcher at tiie server which takes, for example, one 
of a pair of actions based on whetiier the client is a network terminal. If the client terminal is a network terminal, then 

30 the application dispatcher starts a server application in the server which responds to the client application in tiie client. 
Gioing fonward, the server application responds to all future requests from tiie client application. If the client is a non- 
network terminal, then the application dispatcher initiates a client application in tiie server to service the client terminal 
application requirements. Requests from the client application on behalf of the client terminal are subsequently serv- 
iced by a server application at the server which communicates to the client terminal via the client application at the 

35 server. 

[0020] A network terminal in accordance with one embodiment would execute Java applications in stand-alone mode, 
but have tfie capability to interact with a server for such functions as retrieving information, database processing, mas- 
sive computation processing, and access to shared devices such as high-speed printers, plotters, and magnetic tapes. 
[0021] In one embodiment, the application dispatcher includes a listener. The listener is assigned to a particular port 

40 number of the server. The listener is responsible for waiting for new incoming connections from a client terminal (e.g., 
a network terminal or a non-network terminal). When a new incoming connection is detected, the listener dynamically 
instantiates a resolver and passes the connection to tiie resolver. The behavior of the resolver can vary depending on 
the port number and requirements of tiie client terminal. For example, for a network terminal, such as a commercially 
available VeriFone Personal ATM™ (PATM^ appliance or a Personal Computer (PC), the resolver is responsible for 

45 executing "who are you" negotiation and for generating a session key. The listener's dynamic instantiation of the 
resolver functionality can be efficiently implemented using tiie well-known Java^ programming language: for example, 
the listener instantiates the appropriate resolver using the fully-qualified Java dass name, which is provided in config- 
uration data. Accordingly, this embodiment provides an architecture that allows the application dispatcher to efficiently 
and flexibly handle different connection types Involving a variety of different types of network and non-network client ter- 

50 minals utilizing a variety of different protocols. Moreover, new connection types, terminals, and protocols can be added 
without modifying server software. 

[0022] An embodiment of tiie present invention is described below, by way of example only, with reference to the 
accompanying drawings, in which: 

55 FIG. 1 is a block diagram of a computer system, for example, a personal computer system on which ttie inventive 
object-oriented information manager operates; 

FIG. 2 illustrates a client-server network in accordance with a preferred embodiment: 
FIG. 3 illustrates a server architecture in accordance witii a preferred embodiment: 
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FIG. 4 illustrates a client-server architecture in accordance with a preferred embodiment; 

FIG. 5 illustrates a first client request to a server in accordance with a preferred embodiment: 

FIG. 6 illustrates a client server environment which accesses support service in accordance with a preferred 

embodiment; 

5 FIG. 7 is an architecture diagram of a client-server system in accordance with a preferred embodiment; 

FIG. 8 is an architecture diagram of a client-server system in accordance with a preferred embodiment; 

FIG. 9 is an architecture diagram of a client-server system in accordance with a preferred embodiment; 

FIG. 1 0 illustrates the message format utilized in accordance with a preferred embodiment; 

FIG: 1 1 presents a table showing additional details associated with the device types, commands and data blocks. 
10 in accordance with a preferred embodiment; 

FIG. 12 presents additional details on the message format in accordance with a preferred embodiment; 

FIG. 13 illustrates the display commarxls and responses in accordance with a preferred embodiment; 

FIG. 14 presents the status values associated with various operations in accordance with a preferred embodiment; 

FIG. 15 is a communication ftaw diagram in accordance with a preferred embodiment; 
15 FIG. 16 illustrates an application dispatcher that includes listeners in accordance with one embodiment of the 

present invention; 

FIG. 1 7 illustrates the listener controlling a listener proxy and a resolver in accordance with one embodiment of the 
present invention; 

FIG. 1 8 illustrates the listener proxy waiting for new connections in accordance with one embodiment of the present 
20 invention; 

FIG. 19 illustrates the listener proxy detecting a new connection from an appliance in accordance with one embod- 
iment of the present invention; 

FIG. 20 illustrates the resolver handling the new connection from the appliance in accordance with one embodi- 
ment of the present inverrtion; and 
25 FIG. 21 illustrates the resolver starting an application in accordance with one embodiment of the present invention. 

[0023] The described embodiment is preferably practiced in the context of an operating system resident on a compu- 
ter such as a SUN, IBM, HP, or a Windows NT Computer A representative hardware environment is depicted in FIG. 1 , 
which illustrates a typical hardware configuration of a computer 100 in accordance with the subject invention. The com- 
30 puter 100 is controlled by a central processing unit 102 (which may be a conventional microprocessor) and a number 
of other units, all interconnected via a system bus 108, are provided to accomplish specific tasks. Although a particular 
computer may only have some of the units illustrated in FIG. 1, or may have additional components not shown, most 
server computers will include at least the units shown. 

[0024] Specifically, computer 100 shown in FIG. 1 includes a random access memory (RAM) 106 for temporary stor- 
35 age of information, a read only memory (ROM) 104 for permanent storage of the conrputer's configuration and basic 
operating commands and an input/output (I/O) adapter 1 10 for connecting peripheral or network devices such as a disk 
unit 113 and printer 1 14 to the bus 108. via cables 1 15 or peripheral bus 1 12, respectively. A user interface adapter 116 
is also provided for connecting input devices, such as a keyboard 120, and other known interface devices including 
mice, speakers and microphones to the bus 108. Visual oulput is provided by a display adapter 1 18 which connects the 
40 bus 108 to a display device 122, such as a video monitor. The computer has resident thereon and is controll«J and 
coordinated by operating system software such as the SUN Solaris. Windows NT or JavaOS operating system. 
[0025] FIG. 2 illustrates a client-server network in accordance with a preferred eni)odiment. A set of consumer 
devices (client terminals 200) are attached to a server 210 and the server is attached to a legacy host 220 to process 
applications requiring information at the host 220. The connection could be by means of the Internet, a dialup link, token 
45 ring, cellular phone, satellite, Tl or X.25 telco link or other communication means. 

Server Software 

[0026] The sever software is written using a combination of Java, C or possitrfy C++, C or C++ will be used mainly to 
50 inplement platform dependent code (such as dealing with the comm ports). While a preferred embodiment discloses 
support for a dial up network and Internet processing utilizing TCP/IP, one of ordinary skill in the art will readily realize 
that a token ring, SNA or other network, such as those discussed in US Patents (5.530.961; 5,491,796; 5,457,797; 
5.442,791; 5.430.863; 5.394.401; 5,291,597; 5.287.537; 5,287,461; 5.201.049; 4.991.089; and 4,588,211) could be 
readily interchanged as the network. 

55 

Architecture 

[0027] A server architecture in accordance with a prefen-ed embodiment supports two types of client terminals. 
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[0028] Network terminals. These are client terminals capable of directly executing the Java applications on the client 
ternninal which are initially stored on a server. The server will simply download this code to the client's network terminal 
which the client will then execute to provide a particular service. This service may or may not interact with other clients 
or servers. Network terminals can b connected to a server through a dial up modem link, directly through a local area 

5 network, or by ether network communication means in accordance with a preferred embodiment. 

[0029] Non-network terminals. These are clients terminals which are not capable of executing Java applications on 
the client terminal. When dealing With this dass of client the server will execute the application on behalf of the client. 
In this case the server will only expect necessary input and output operations to be performed by the client terminal. An 
example of how to connect a plurality of non-network terminals to a host server is described in US Patent 5.287.461 , 

10 the disclosure of which is hereby incorporated by reference in its entirety. 

[0030] FIG. 3 illustrates a server architecture in accordance with a preferred embodiment. A client 300 would initiate 
a connection with a server 350 by, for example, dialing in to a modem pool which is intercepted by the point-to-point 
stack software 31 1 which conforms information received to the TCP layer 312 which obtains a socket 313 for connecting 
the client 31 0 to the sewer 350. The Java net layer 31 4 further refines the request to conform with the TERM 10 and NET 

15 layer 315 which passes the request along to the application dispatcher 319. The application dispatcher 31 9 spawns the 
appropriate server application selected from the server applications 330. On a non-network terminal, the non-network 
terminal initiates a "first connection" by dialing up a modem, for example. The dial up goes through the native OS 316 
(Solaris or Windows NT dial up layer) and is connected with the serial comnrrunication in the VFI.SERIAL layer 317 
which abstracts the serial input/output functions into a higher level communication layer. The VFI.NET layer 315 takes 

20 the abstracted serial layer and maps it into a similar communication as the communication from the network terminal 
300. It makes the dialup asynchronous connection appear to the server application as a new socket connection. 

Network Terminal - "First Connection" 

25 [0031] FIG. 4 illustrates a client-server architecture in accordance with a preferred embodiment. The architecture is 
illustrated initially for a network terminal for clarity and then follows with a non-network terminal. Processing com- 
mences at 400 when a network terminal requests connection through a layered communication system to a set of 
server threads 420 which are triggered by a detection of a "ring" 430 to initiate possible client updates and the subse- 
quent client application to server application processing. "Ring" refers to a "first connection" in socket processing in 

30 accordance with a preferred embodiment. 

[0032] The network terminal makes its connection through the Point-to-Point-Protocol stack 411 utilizing the TCP 
layer 412 and the sockets layer 413, which is like an electrical socket, for attaching terminals to communication sockets 
to facilitate communication through the network. All of this is managed by the Java.net 414 which connects the socket 
1 11 1 via the TCP layer 412 and the PPP stack 411. The layer above is the VFI.net and VFI.TERMIO 415 which is 

35 responsible for detecting that the connection is made and mapping the connection to an application dispatcher 431 to 
further process the first connection (ring) request. 

[0033] The server 450 waits for a '*first connection" request much like an interrupt manager. When a "first connection" 
request arrives, then the application dispatcher has a method that detects a connect request or a LAN "first connection" 
request that would arrive through the TCP layer as a socket connect. That connection is translated into a logical ring 

40 which is equivalent to an event or interrupt. The server 450 responds to the "first connection" with a query initiated by 
the applicaton dispatcher 431 requesting "who are you" via an enquiry message asking for identification by the client 
loader thread 42 1 . The network terminal responds with ID information, including the identification of the application that 
the network terminal requires. If the terminal answers with an identifier indicating that the terminal is a network terminal, 
then the client loader thread 421 performs any necessary client application updates via a download using a file transfer 

45 program such as UDP or FTP, or any other socket layer protocols that are available for network file transfers to the net- 
work terminal 400. 

Network Terminal - First Client Request to Server 

50 [0034] FIG. 5 illustrates afirst client request to a server in accordance with a preferred embodiment. When a first client 
request is transmitted from the network terminal 500 with a client application resident thereon 510 to the server 550, 
the application dispatcher 530 spawns the corresponding server application 520 for servicing the request at the server 
550 via the assigned socket 1112. The server application 520 responds to the request and transmits information to the 
network terminal 500. The application dispatcher 530 has completed its responsibilities for this client 500 and can 

55 return to a wait state until the next "first connection" request from a client. The client application request could be as 
simple as a get current time request or a request for data from a server database. 
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Network Terminal - Subsequent Client Request to Server 

[0035] FIG. 6 illustrates a network terminal 600 with a downloaded client application 610 which accesses support 
services in the sender 650 through its assigned sender application 620 in accordance with a preferred embodiment. The 
5 terminal 600 communicates to a server application 620 which accesses host processing capabilities and database 
services 640 to service requests emanating from the client application 610. The server application 620 handles any 
events that originate from the client application 610 via the assigned socket 1 112. These events could include data 
requests from a database application, or data transfer to a server Remote data from another server application could 
also be accessed by the client. Server application 620 accuses support services directly or via a socket interface 660. 

10 

Non-network Terminal - "First Connection" 

[0D36] FIG. 7 is an architecture diagram of a client-server system in accordance with a preferred embodiment. A lay- 
ered communication system 700 is used by a non-network ta'minal 710 to detect a ring providing an indicia of commu- 

15 nication 740 and dispatch an application 730. Dispatching an application 730 also initiates a server thread 720 for 
servicing the client request. The non-network terminal 710 initiates a "first connection" by dialing up a modem, for 
example. The dial up goes through the native OS 71 1 (Solaris or Windows NT dial up layer) and is connected with tiie 
serial communication in the VFI.SERIAL layer 712 which abstracts the serial input/output functions into a higher level 
communication layer. The VFI.NET layer 71 5 takes tiie abstracted serial layer and maps it into a similar communication 

20 as the communication from tiie network terminal. It makes the diaiup asynchronous connection appear to the server 
application as a new socket connection 1111. The communication is an event 740 that triggers actions by the applica- 
tion dispatcher 741 which responds to tiie "first connection" event by requesting ID information from the client, via an 
enquiry message, and starting tiie requested client application 720 at the server 750. 

25 Non-network Terminal - First Client Request to Server 

[0037] FIG. 8 is an architecture diagram of a client-server system in accordance witii a preferred entsodiment. The 
client application 822 is responsible for managing the non-network terminal 810. The client application 822 writes infor- 
mation, utilizing a server version of VFI.TERMIO 855, to and responds to key presses by the non-network terminal 810 

30 at tiie server 850. The client application 822 initially makes a request for service from a socket 1112 that is associated 
witii the non-network terminal 810 when tiie application dispatcher 840 spawns the client application 822. 
[0038] When the first request 845 is generated by the client application 822 residing on the server 850, at application 
startup, the first request for service is routed in the server 850 to the application dispatcher 840 and spawns the server 
application 820 which will handle subsequent requests. The server application 820 makes a request for service from a 

35 socket 1112 that is associated witii tiie client application 822 which transmits an appropriate command through the 
VFI.TERMIO 855 to the VFI.SERIAL layer 856 using the operating system communication support 857 to tiie non-net- 
work terminal 810. This processing is identical to tiie network terminal processing witii tiie exception tiiat all applica- 
tions reside on the sender 850 as opposed to a Java application executing remotely on tiie network terminal. 
[0039] One advantage of Java is that it is machine independent and does not care whetiier a Java application resides 

40 on tiie client or the server. In the case of the non-network terminal, tiie client application resides in the server and con- 
trols the Java incapable terminal. 

Non-network Terminal - Subsequent Client Requests to Server 

45 [0040] FIG. 9 is an architecture diagram of a client-server system in accordance witii a preferred embodiment. A lay- 
ered communication system 900 is used by a non-network terminal 910 to manage tiie interconnection of a server 
Application 940 to a client application 920 and facilitate communication between tiie terminal 91 0 and server application 
940 via a client application 920 resident on the server 950. FIG. 9 shows the processing after tiie first request has been 
completed and tiie client application 920 is coupled with tiie server application 940 via the assigned socket 1112 just 

50 as in tiie network terminal example, except the client application 920 and server application 940 both reside on tiie 
server 950. 

[0041 ] If a terminal responds with a message that indicates rt is a non-network terminal, then tiie terminal is supported 
witii the command streams described in FIGs. 10-14. If tiie terminal is a network terminal, ttien tiie application is down- 
loaded via a FTP or ottier network file transfer procedure. 
55 [0042] FIG. 10 illustrates the structure of a packet in accordance with a preferred embodiment. FIG. 1 1 shows tii 
format of each field of a communication and describes the contents of the same. For example, ttie header is tw bytes 
in lengtfi and has various values that correspond to different types of transacti ns. Similarly, the Packet Type. Header 
CRC, Sequence #, Data Block and CRC-1 8 fields are described in ttie table set fortii in FIG. 11. 
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[0043] FIG. 12 r^resents a table showing additional details associated with the device types, comnnands and data 
parameters. For example, the device type field is one byte long and specifies the selected Input/Output device. FIG. 13 
illustrates the display commands in accordance with a preferred embodiment. The display's device type is zero. FIG. 14 
presents the status values associated with various requested operations in accordance with a preferred embodiment. 

5 [0044] FIG. 1 5 is a communication flow diagram in accordance with a preferred embodiment. A terminal 1 500 either 
has firmware or an application 1504 that initiates a connection 1506 (with a server 1502 by contacting a dispatcher 
1 508. The connect initiate 1 506 also connects a socket 1 1 1 1 to handle the connection. The dispatcher 1 508 transmits 
an identification enquiry 1510 which the client terminal replies to with an identification message 1512. In the case of a 
network terminal, the dlent loader 1522 performs any necessary client application updates 1520 on the client terminal 

10 1 500. In the case of a non-network terminal, the dispatcher starts the client application. The client then sends a request 
to start the server application 1530 to the server which results in the connection of a socket 1 1 12 and the server appli- 
cation 1550 being started and a confirmation message 1532 being transmitted back to the client application 1540. 
Then, when the client application 1540 requests data 1542 from the server application 1550, the server application 
1550 responds with the application response data 1560. 

15 

Application Dispatcher - Control Flow Application Dispatcher startup 

[0045] Configured modem ports that will take part in transactions are pre-configured. The Application Dispatcher (AD) 
startup code looks at this configuration stream to determine the number of S threads (serial port listeners). S classes 
20 instantiate a VFI.NETserversocket object which in turn create a VFI.NET.ModemlO.ModemPort object. The I^odemP- 
ort object binds to a low level VFI.NET.ModemlO.Port object which utilizes native methods to configure and wait on the 
communications port. 

SO 

25 

{ 

serversocket SOSocket = new serversocket ("spcketl I H",l); //Listener 

30 object 

{ 



35 

socket SOCoiiiiSocket=SOSockeLacceptO; // Translates to 
WaitDevice(CONfNECT) 
40 ReadAndValidate (RequestID); 

return RequestID, SOConnSocket; 

} 

45 



Request Processing 

[0046] As illustrated above. S threads are transient threads. And even when alive they perform efficient waits (No CPU 
cycles are consumed). The AD receives the RequestID from each S thread. Request processing is performed by data- 
55 base lookup. Typically Requests, are sinple text messages with delimiters and are parsed using a StringTokenizer 
object. 

StringTokenizer stParseHelp = new StringTokenizer ((String) Request); 
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field 1 = stParseHetp.nextTokenO; 
field2 = ....andsoon. 

[0047] The AD will query a database to determine which applications should be initiated based on the enquiry mes- 
sage utilizing an SQL query of the form: 

"SELECT (Field Class Path)from (TableName) where <f1=fieldl and >, 

is handled by the JDBC layers to return data to the AD. The AD is now ready to run the client thread. 

ClientThread=new Thread (field 1, field2.... SOConnSocket); 

[0048] The field list contains appropriate fields (those required for client application processing) and are passed down 
to the client thread along with the connected socket object. 

Client Threads 

[0049] Client Threads proxy the actual application. Application output meant for the terminal's devices are routed out 
using VFI.TERMIO as directives to the client terminal's firmware. The connected socket (which translates to a live dial- 
up connection) is passed down from the AD to the client thread. Client threads are long living - usually transferring data 
to corresponding servlets that initiate connections to upstream hosts or make database transactions. Despite the fact 
that client threads can be JDBC aware, servlets handle database transactions. This helps to maintain code constancy 
when the same client class is downloaded to a Java capable terminal for remote execution. 

[0050] Terminal I/O is performed through a VFl.TermlO object that in turn instantiates a VFl.TermlO.ServProtocol 
object. The protocol object implements the actual data transfer with the client terminal. The protocol object requires the 
socket object passed down from the AD to the client thread. 

CO (Appropriate Request fields, SOConnSocket) 

{ 

VFl.TermlO lOObject = new TermlO (SOConnSocket)y/IO object 
//instantiation. This cascades into a ServProtocoI Object instantiation. 

lOObject. WriteString (Stringlndex); //Displays a particular string on the P- 

ATM. 

//If the client needs to retrieve data from upstream hosts (OnmiHost, VISA 
etc.), //or needs data from a database it makes a TCP stream connection to a 
servlet. 
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//This is consistent with the behavior of the network terminal which would 
//make the same connection over PPP. 

clienTransObject = new Socket (<Host>, <WeIl known socket>); 
//Explained further down under initial client requests 

//Further processing 

//Send out host requests 
clienTransObject write (HostRequest); 
clienTransObjectread (HostResponse); 

lOObject-WriteString (Stringlndex + n);//Displays status on the P-ATM. 



25 



30 



35 



40 



45 



Initial Client Request processing 

[0051] The AD runs a T thread (spawned off during startup) that listens on a well-known socket (e.g. 1112) waiting 
for initial ClientRequests from a client application. The T thread processes the ClientRequest to determine which servlet 
class needs loading. 

T 
{ 

ClientlnitialRequestListener = new ServerSocket (<wellknown socket (e.g. 
1112)>); 

//Wait for initial requests and spawn off server connSocket = 
Clientini tialRequestListener.accept() ; 

connSocketStream.read (InitialRequest); 
Parse (InitialRequest); 



HostThread HO = new Thread (connSocket, "class name"); 

50 

} 



55 [0052] The T thread is a daemon thread and lives as long as the AD lives. When the client application is downloaded 
to a Java capable terminal initial requests arrive over the PPP link. 
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Host Threads or Servlets 

[0053] Host Threads (H) service client requests for upstream and database connectivity. A host thread can make TCP 
connections with remote hosts, forward financial transactions originating from the client application and route the 
5 response. 

HO (connSocket) 

{ 

10 

connSocket. Stream.read (ClientRequest); 
ParseRequest (StringTokenizer); 

75 

Socket upstreamSock = new Socket (upstreamHost, Port); 



20 //Transact 



connSocket-Stream. Write (HostResponse); 



30 Transient and Long-living Threads in the Application Dispatcher A sockets based abstraction of the Win32 Communi- 
cation API 

[0054] Consistence in the access of transport layer services needs no over emphasis. The design of the PIS server 
aims to provide a uniform interface to third party client component and server component applet writers to the async 

35 dial-up protocol module and the system's TCP/SLIP/PPP stack. This interface comprises a set of Java Classes collec- 
tively called VFI.NET*. It should be noted that this package does not provide pure TCP/UDP/IP specific objects and 
methods that are already defined and implemented in java.net.*. Programmers, however, do not need to explicitly 
import java.net.*. This is automatically done by the package. Further, this document does not discuss the functionality 
of java.net. * which may be found in the appropriate JDK documentation. It merely, details a dass design that overloads 

40 methods specifically necessary to build a BSD sockets like layer between calling applets (servlets) and the machine 
specific Java serial communications package. 

Hierarchy 

45 [0055] A uniform upper edge interface for the ModemlO classes permits easy replacement of the implementation. The 
actual modem handling code, for instance, may use the TAPI client calls instead of direct Win32 communication calls. 
Multiple libraries that conform to the same interface allow different link level protocol stacks (like MNP3). This ensures 
the constancy (and hence direct portability) of VFI.ModemlO.*. 

50 Required l^odemlO Functionality 

[0056] 

1 . Open an end-to-end async, duplex dial-up connection. The station address (InetAddress as in TCP/IP) is the dial 
55 String. Configure upon connection, 

2. Listen for an incoming dial-up connection. The listen port (analogous to the bound TCP port) is the COM port. In 
this regard the valid port numbers range from 0 - OxFF (which is the maximum number of COM ports allowed in 
NT). Configure upon initialization. 
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3. Obtain Input and Output steams that re-direct from/to the open connection. 

4. Hang-up (dose as in TCP/IP) a live connection. 

[0057] The following classes form a part of VFI.ModemlO.*:- 

Raw Serial Port Handling 

[0058] 

public class VFI.ModemlO.Port 
{ 



//Constructors 

public Port (int nPortNum); 

public Port (int nPortNum, int nBaud, int nParity, int nDataBits, 
nStopBits); 

public Port (int nPortNum, String sCfgStr); 

public Port (String sPortName); 

public Port (String sPortName, String sCfgStr); 

//Methods 

public void closeQ; 

public int getPortlDQ; 

public String getPortNameQ; 

public String getCfgStrO; 

public InputStream getlnputStreamQ; 

public OutputStream getOutputStreamQ; 
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Modem initiation and methods 
[0059] 

public class VFI.ModemlO.ModemPort 

{ 

//Constructors 

public ModemPort (int nPoilNum); 

public ModemPort (Port objPort); 

public ModemPort (String sPortName); 

public ModemPort (int nPortNum, String slnitString); 

public ModemPort (Port objPort, String slnitString); 

public ModemPort (String sPortName, String slnitString); 

//Methods 

public Port getPortO; 

public boolean connect (String sDialString); 



public void disconnectQ; 
public void resetQ; 

public boolean configure (String sCfgStr); 
public boolean configureDM (String sCfgStr); 



[0060] Programmers must use getPortO to capture a stream and transfer data over the ModemPort. Conf igure(String) 
sends out an AT command and returns TRUE If the modem returned 0K<a>(1f ).configureDM(String) sends out the 
same command to the modem when in data mode. 

NET - The Sockets wrapper 

[0061 ] The package encapsulates two major classes found in java.net.*-Socket and ServerSocket. To present a famil- 
iar interface and yet avoid conflicts, the package instantiates its own socket and serversocket objects via constructors 
that take an extra parameter (that identifies the lower object that needs to be instantiated). ITiis is illustrated after the 
dass definition. 

Station address resolution 

[0062] The InetAddress object refers to an unique long value that corresponds to the machines TCP/IP address. The 
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async dial-up line may however use multiple COM ports to open a connection with the host. Heurlstlcally, it may seem 
that fitting the TCP/IP host/iTOChine address into the native COM support library will permit overloading of InetAddress 
and hence enhance elegance. This, however, results in extra and avoidable complexity. In this regard. InetAddress will 
still correspond only t a TCP/IP address. The versions of the java.net.Socket constructor that accept the host name 

5 (as a String) will, instead, be overloaded. This value will now refer to a dial String that identifies the remote station 
address- 
Socket initialization and connection 

10 [0063] 

public class VFLNET.socket 
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{ 

//Constructors 

public socket (String sHost, int nPort, int nProtocolType); 

/* nProtocolType may take one of two values: 
PF_INET #defmedto 1 
PF_VFI_PTS_MODEMIO #defined to 2 

Passing a value of 0 causes the use of 
java.net.Socket */ 

//Methods 

public void closeQ; 

public String getStationAddressQ; 

public int getPort(); 

public InputStream getInputStream(); 

public OutputStream getOutputStreamQ; 

} 

public class VFI.NET,serversocket 
{ 

//Constructors 

public serversocket(int nPort, int nProtocolType); 

/* . nProtocolType may take one of two values; 

PF_rNET#definedto 1 

PF_VFI_PTS„MODEMIO #defmed to 2 

Passing a value of 0 causes the use of java.net.ServerSocket.* 

//Methods 

public socket accept(); 
public void closeQ; 
public int getPort(); 

> 
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Interface Library to native Win32 Comm. API methods 
[0064] 

5 HANDLE OpenDevice (int nDevNum, DCB * pNewDCB); 

void CloseDevice (HANDLE hDevice); 

int WriteDevice (HANDLE hDev, int nBytesToWrite, unsigned char *pWriteBuf); 
int ReadDevice (HANDLE hDev, int nBytesToRead, unsigned char * pReadBuf); 
BOOL ConflgureDevice (HANDLE hDev, DCB * pNewDCB); 

10 

Application Dispatcher Architecture 

[0065] FIG. 16 illustrates an application dispatcher 1600 that includes listeners 1604, 1606, and 1608 in accordance 
with one embodiment of the present invention. AppManager 1602 starts listeners 1604, 1606, and 1608, For example, 
15 AppManager 1602 starts a listener for each type of connection as defined in the database (e.g., shown and discussed 
above with respect to FIG. 6). Each listener is responsible for managing applications associated with its type of connec- 
tion (e.g.. TCP/IP, phone line concentrator, and serial port connections). Each listener is assigned to a particular port 
number of the server. 

[0066] FIG. 1 7 illustrates listener 1 604, which controls a resdver 1 702 and a listener proxy 1 704 in accordance with 
20 one embodiment of the present invention. Thus, AppManager 1602, which is shown in FIG. 16. controls resolver 1 702 
(e.g.. a resolver thread instantiated by listener 1604) and listener proxy 1704 (e.g.. a listener proxy thread instantiated 
by listener 1604). In one embodiment, each listener started by AppManager 1602 controls two other entities: a single 
listener proxy thread, which manages new connections; and many resolver threads, which are responsible for starting 
the appropriate server application. 
25 [0067] FIG. 18 illustrates listener proxy 1704, which is controlled by listener 1604, waiting for new connections in 
accordance with one embodiment of the present invention. Listener proxy 1 704 is responsible for placing new connec- 
tions in a new connection queue of listener 1604. 

[0068] FIG. 19 illustrates listener proxy 1704 detecting a new connection 1902 from an appliance 1904 (e.g., a net- 
work terminal, such as a commercially available VerlFone PATM™ appliance or a PC) in accordance with one embodi- 
30 ment of the present invention. Listener proxy 1704 places the new connection in the new connection queue of listener 
1 604. Listener proxy 1 704 then continues to wait for new connections. The maximum size of the new connection queue 
is configurable. 

[0069] FIG. 20 illustrates resolver 1702 handling new connection 1902 from appliance 1904 in accordance with one 
embodiment of the present invention. In particular, upon detecting a new connection in the new connection queue, lis- 
35 tener 1604 instantiates resolver 1702. Listener 1604 passes new connection 1902 to resolver 1702. 

[0070] For example, if appliance 1 904 is a network terminal, such as a commercially available VeriFone PATM™ appli- 
ance or a PC, then resolver 1702 is responsible for executing 'Nwho are you" negotiation and for generating a session 
key. A variety of resdvers can be provided for a variety of appliances communicating via a variety of protocols. Exam- 
ples of appliances include a commercially available VeriFone PATM^" appliance, a PC, a merchant Point Of Sale (POS) 
40 device, a cellular telephone, or a pager. Examples of protocols include TCP/IP, X.25. or a proprietary protocol. 

[0071] In one embodiment, the listener's dynamic instantiation of the resolver functionality can be efficiently imple- 
mented using the well-known Java™ programming language: the listener can instantiate the appropriate resolver using 
the fully-qualified Java dass name, which is provided in configuration data (i.e., resolver names are configurable). 
Accordingly, the functionality of the server can be enhanced without additional code modifications. 
45 [0072] FIG. 21 illustrates resolver 1702 starting an application 2102 in accordance with one embodiment of the 
present invention. In particular, resolver 1702 interrogates appliance 1904 to determine its type and capabilities. 
Resolver 1702 then consults the database (e.g., as shown and discussed above with respect to FIG. 6) to determine 
which application to start. Reiver 1702 then starts the appropriate application, (in this example) application 2102. 
Application 2102 now controls appliance 1904. For example, connection 1902 is handled by low-level application inter- 
so face libraries of application 2102. 

[0073] Altiiough particular ent}odiments of the present invention have been shown and described, it will be obvious 
to those skilled in the art that changes and modifications can be made without departing from the present invention in 
its broader aspects. For example, the application dispatcha^ can be implemented in a variety of programming lan- 
guages and programming techniques, such as object-based programming techniques using the well-known Java™ pro- 
55 gramming language, th well-known C programming language, the well-known C++ programming language, or any 
combination thereof, claims are to encompass within their scope all such ch 

[0074] The disclosures in United States patent application no. 09/121 ,206. from which this application claims priority, 
and in th abstract acconpanying this application are incorporated herein by reference. 
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Claims 

1 . A method for an application dspatcher for server application support for a plurality of client tern^'nals, the client ter- 
minals in communication with a server via a network, the method comprising: 

5 

a client terminal initiating a connection to the server utilizing the network; 

the server listening for the connection utilizing the application dispatcher, the application dispatcher starting a 
listener, the listener detecting the connection, the application dispatcher starting a resolver for the client termi- 
nal in response to the detecting of the connection, and the resolver handling tiie connection; and 
10 the server determining if the client terminal is a network terminal or a non-network terminal. 

2. The method as recited in Oaim 1 wherein: 

if the client terminal is a network terminal, a client loader on the server updating a client application, if neces- 
15 sary, on tiie client terminal utilizing the network and starting a server application to service future requests from 

tiie client terminal; and 

if the client terminal is a non-network terminal, the server initiating the client application and the server appli- 
cation on the server for processing the client application at the server for tiie client terminal. 

20 3. The method as recited in Oaim 1 comprising: 

tiie application dispatcher starting a plurality of listeners, wherein each listener Is provided for a predetermined 
type of connection, each listener being responsible for managing an application associated with Its type of con- 
nection. 

25 

4. The mettiod as recited in Claim 1. wherein tiie listener controls a listener proxy and a resolver. tiie listener proxy 
detecting the connection, the resolver starting an appropriate sen/er application for the connection initiated by the 
client terminal. 

30 5. The metiiod as recited in Claim 4, wherein the listener proxy places the connection In a new connection queue of 
the listener, and the listener proxy then continues to wait for new connections. 

6. The method as recited in Claim 1 , wherein the client terminal comprises a network terminal, the resolver for the net- 
work terminal being responsible for executing ^who are you" negotiation and generating a session key 

35 

7. The method as recited in Claim 1 comprising: 

tine resolver inten-ogating the client terminal to determine its type and capabilities; and 
the resolver consulting a server database to determine which application to start. 

40 

8. The method as recited in Claim 1 . wherein ttie listener starting tiie resolver, comprises: 

the listener dynamically instantiating tiie resolver. wherein the listener Instantiates the resolver utilizing a 
resolver name, tiie resolver name being provided in configuration data. 

45 

9. The method as recited in Claim 8. wherein tiie resolver name comprises a fully-qualified Java class name. 

10. The method as recited in Claim 1 . wherein tiie network comprises a dial-up network connection. 

50 1 1 . A system for an application dispatcher for server application support for a plurality of client terminals, tiie client ter- 
minals In communication witii a server via a networK the system comprising: 

a client terminal, tiie client terminal comprising client logic for initiating a connection to ttie server utilizing the 
network: 

55 the server, the server comprising server logic for listening for tiie connection utilizing the application dispatcher, 

the application dispatcher starting a listener, the listener detecting the connection, the application dispatcher 
starting a resolver for the client terminal in response to the detecting of the connection, and ttie resolver han- 
dling ttie connection, and the server further conrprlsing logic for determining if the client terminal is a network 
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terminal or a non-network terminal. 

12. The system as recited In Claim 1 1 , the server logic further comprising: 

if the client terminal is a network terminal, a client loader on the server updating a client application, if neces- 
sary, on the client terminal utilizing the network and starting a server application to service future requests from 
the dient terminal; and 

if the client terminal is a non-network terminal, the server Initiating the client application and the server appli- 
cation on the server for processing the client application at the server for the client terminal. 

13. The system as recited in Claim 1 1 , wherein the client terminal comprises a network terminal for the network termi- 
nal being responsible for executing "who are you" negotiation and generating a session key. 



17 



EP 0 978 976 A2 




18 



EP 0 978 976 A2 




19 



EP 0 978 976 A2 




20 



EP 0 978 976 A2 




21 



EP 0 978 976 A2 




22 



EP 0 978 976 A2 



tx: 



< 

LLi 
CO 



O 

o 

CM 
CO 




Q. 
CL 
< 



=3 <n 
CO 09 





r 


1 




"S5 




<D 


o 




<n 


X 




ba 


'c 




eg 


E 




to 


O 







o 

< 
o 

_l 
Q. 



CO 

LL 



O 
CO 



23 



EP 0 978 976 A2 




24 




25 




26 



EP 0 978 976 A2 



O 



8 
m 

"15 
a 



8 

c: 
<D 

n 
cr 

CO 



O 

o 

<D 
"O 
<0 
<D 



CO 

< 



€Q 

X 



O 
CO 

o 

Q. 

? o 

o — 

CO 

E 

E 
o 
o 



E 
o 



CO 



c 

o 
o 
c 
Ul 

o 

E 

E 
>* 

CO 
o 
m 



OH 
a> 



O 

O 

-o 

c: 

CO 
09 



2 

>^ 
(O 
Q. 
CO 

Q 

E" 

CO 

>* 
CO 

'> 
Q> 
X? 

CO 
CD 



<o 

o 

CO 
CO 



CD 



CD 
O 

■> 
CD 

Q a> 

-Q - 
rs 
CO 



CD 



(D 
CX 
CD 
"O 

CD 



CD 
O 

CD 

Q 

^co 

c= 

CO 

E 

E 
o 
O 



CO 

E 

E 
o 
O 



1 

CO 
CD 

cr 

_ e a? 

^ i "s 

e ^ 

CO 

to 



CD 
O 

'> 
CD 
O 



CO 

no 

CO 

E 
E 

<3 

CO 

CD 
CO 



CO 

cx 
_cg 
fS 

•o 

cr 

CO 

e 

E 
o 

CD oi 
c» 
S *° 

CO CO 
CD <D 



E § 

E » 

<^ «H 

- » CO 

O O CO 

U- U- XI 



A 

_a> 

CO 

-sr 

CO 

> 

V 



E 
2 

CO 

cx 



CM 

O 
LL 



27 



EP 0 978 976 A2 



Name 


Size 


Remarks 


Header 


2 bytes 


Has the value Ox55(LSB) 


Packet Type/ 
Byte Count 


2 bytes 


The Packet Type Is contained in the most 4 significant 
bits, b15 - b12. This determines if it is a test packet. 
(xx\\kA packet or data (command or response) packet 
Control Packet 

• ACK 

• NAK 

Data (Command or Resoonse) Packet 


ivimc DiuuiVd lu luuuw 

• LastBk)ck 

* Data Encrypted/Non -encrypted 
Test Packet 

Server Initiated Test Mode , loopback 

The Byte Count is contained in the renfiaining 12 bits, 
b11 - bO (4095 max value), the size of the Sequence # 
and Data Block. 


Header CRC 


2 bytes 


Checksum of the Packet Type/Byte Count For ACK 
and NAK packets, this is the last transmitted data. 


Sequenced 


1 byte 


Optional field, valid only for non-ACK/NAK packets. 
Start bkx;k is always 0. subsequent bk)cks will be 
incremented by 1. 


Data Block 


Byte Count -1 


Optional fiekl, valid only for non-ACK/NAK packets. 
The Command or Response Message may be broken 
up into smaller packets (blocks), and may further be 
encrypted. 


CROW 


2 bytes 


2 byte CRC calculation, from Sequence # to the last 
byte of the Data Block field. It is ttie standard 16-bit 
CRC-CCITT algorithm: 
G(x) = X»8+x'»+x5+1 



FIG. 11 
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Command 


Descnpbon 


Data Param^ers 


0 


Store text string into NV 
mennory. 


Tat>te, offeet, string. 


1 


Display raw text. 


String, columa 


2 


Display preset prompt from NV 
merDory. 


Tal)le, offset column. 


3 


Set tocal echo. 


None. 


4 


Gear local echo. 


None. 


5 


Set secure echo (display ). 


None. 


6 


Clear secure echo. 


None. 
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Status 


Description 


0 


Successful operation. 


1 


Invalid command. 


2 


Too many characters. 


3 


Illegal prompt selection. 
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FIG. 18 




Appliance 



FIG. 19 
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FIG. 20 




